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Abstract 


We  consider  the  problem  of  getting  a computer  to  follow  reasoning  conducted  in  dynamic 
logic.  This  is  a recently  developed  logic  of  programs  that  subsumes  most  existing  first-order 
logics  of  programs  that  manipulate  their  environment,  including  Floyd's  and  Hoare's  logics  of 
partial  correctness  and  Manna  and  Waldinger's  logic  of  total  correctness.  Dynamic  logic  is  more 
closely  related  to  classical  first-order  logic  than  any  other  proposed  logic  of  programs.  This 
simplifies  the  design  of  a proof-checker  for  dynamic  logic.  Work  in  progress  on  the 
implementation  of  such  a program  is  reported  on,  and  an  example  machine-checked  proof  is 
exhibited. 
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A PROOF-CHECKER  FOR  DYNAMIC  LOGIC 


S.D.  Litvintchouk  and  V.R.  Pralt 
Massachusatts  Institute  of  Technology 
Cambridge,  MA  02139 


Introduction 


The  lotiol  language. 

Our  objective  is  to  be  able  to  discuss  programs  with  a computer.  The  prerequisites  are  a 
language  for  holding  the  conversation  in,  and  reliable  criteria  for  following  a line  of  reasoning 
expressed  in  this  language.  We  adopt  a simple  language  having  just  four  basic  constructs. 
Three  of  these  constructs  come  from  ordinary  logic;  they  are  function  symbols,  predicate 
symbols,  and  logical  connectives.  (We  lump  constants  and  variables  together  with  the  leroary 
function  symbols.)  The  fourth  construct,  while  not  a familiar  one  in  logic,  is  nevertheless  one 
that  occurs  in  everyday  conversations  about  programs;  it  is  the  notion  of  "after  executing 
program  et,"  For  example  we  may  say  in  ordinary  conversation,  "After  executing  the  program 
Xml,  X is  equal  to  1." 

While  these  four  constructs  may  not  seem  very  much  to  go  on,  they  are  in  fact  sufficient 
for  almost  any  "first-order"  conversation  about  the  input-output  behavior  of  programs.  They 
may  express  such  diverse  concepts  as  partial  correctness,  termination,  equivalence,  determinism 
versus  nondeterminism,  totality,  reversibility  of  a process,  accessibility  of  states,  weakest 
antecedents,  strongest  consequents,  weakest  and  strongest  invariants,  and  convergents.  They 
also  shed  new  light  on  the  axioms  relevant  to  quantifiers  in  first-order  predicate  calculus  by 
treating  them  from  the  programmer's  point  of  view  rather  than  the  logician's. 

We  abbreviate  "after  executing  program  a"  to  Ca],  so  that  the  observation  of  the  first 
paragraph  condenses  to  CXmllX^l.  (We  have  found  it  convenient  in  conversation  to  pronounce 

as  "box  «.")  We  shall  later  find  useful  the  dual  concept  -'Ca]->  which  we  write  <a>, 
pronounced  "diamond  ou"  The  notation  is  borrowed  from  modal  logic.  Dynamic  logic  is  more 
intimately  connected  with  modal  logic  than  one  might  at  first  suppose;  the  connection  is 
discussed  in  more  detail  in  section  3J2  of  C21].  Fischer  and  Ladner  C6]  demonstrate  the 


connection  between  various  restrictions  of  dynamic  logic  and  the  classical  systems  K,  T,  S4  and 
SS  of  modal  logic.  We  call  Co]  and  <a>  modalities  (respectively  box  and  diamond  modalities), 
and  formulae  of  the  form  CoDP  and  <o>P  modal  formulae.  We  shall  call  a quantifier-free  logic 
augmented  with  such  modalities  a dynamic  logic.  Syntactically,  modalities  behave  exactly  like 
logical  negation;  they  are  placed  in  front  of  a formula,  and  their  precedence  is  such  that 
CoDPaQ  is  parsed  (Co]P)aQ,  just  as  -•PaQ  would  have  been  parsed  (-<P)aQ. 

The  programming  language 

In  order  to  understand  the  meaning  of  a formula  such  as  -•[X:=l]false,  we  first  need  a precise 
account  of  X*.=l.  We  shall  think  of  programs  solely  in  terms  of  their  effect  on  the  state  of  the 
world.  A state  is  defined  by  the  values  taken  on  by  the  function  and  predicate  symbols  of  the 
language  in  soma  domain.  (A  logician  weuld  call  a state  an  interpretation.)  We  call  the  set  of 
all  possible  states  (keeping  the  domain  fixed)  the  universe.  Thus  a universe  is  defined  by  the 
available  function  and  predicate  symbols  and  the  choice  of  domain. 

We  could  restrict  our  attention  to  deterministic  programs,  permitting  us  to  think  of  them  as 
functions  from  states  to  states.  As  we  shall  see  later  however,  reasoning  nondeterministically 
about  deterministic  programs  can  simplify  the  argument.  Hence  we  shall  allow  for 
nondeierministic  programs  by  capturing  the  effect  of  a program  on  a universe  as  a binary  relation 
on  that  universe.  This  of  course  means  that  we  will  be  able  to  discuss  nondeterministic 
programs  in  general.  However,  the  question  of  what  first-order  facts  one  wants  to  assert 
about  nondeterministic  programs  is  presently  the  subject  of  much  discussion  in  the  literature  (see 
CS]  in  particular),  and  we  shall  avoid  that  issue  in  this  paper  beyond  observing  that  dynamic  logic 
as  presented  here  can  express  many  useful  ideas  about  nondeterministic  programs. 

In  treating  programs  as  binary  relations  we  shall  make  use  of  the  usual  notation  that  SaS  is 
true  just  when  ^ and  ^ are  related  by  a.  It  is  convenient  to  identify  the  relation  a as  its  graph, 
the  set  of  pairs  of  states  related  by  a. 

Progratiming  constructs 

The  programs  we  want  to  discuss  have  five  constructs.  These  constructs,  while  not  all 
entirely  conventional,  have  been  chosen  primarily  for  the  ease  with  which  one  can  discuss 
programs  written  using  them. 

(i)  Assignments.  X:=l  is  an  instance  of  an  assignment,  as  is  C(l,K):=C(l,K)«^A(l4)xB(J,K).  In 
general  an  r.ssignment  is  a pair  of  terms  (respectively  the  left-hand  and  right-hand  sides  of  the 
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assignment)  of  our  logical  language.  (A  term  is  an  expression  constructed  solely  from  function 
symbols.)  We  shall  take  xeroary  function  symbols  to  be  ordinary  variables.  Then  when  the 
left-hand  term  is  simply  a zeroary  function  symbol  the  assignment  is  simple  variable  assignment; 
for  ether  left-hand  sides  we  have  array  assignments.  Formally,  the  simple  variable  assignment 
X:st,  where  t is  an  arbitrary  term,  is  {(3,|)|X^=tj  and  otherwise  S=^}.  (X^  denotes  the  value 

of  X in  tj  the  value  of  t in  5.)  Array  assignments  are  slightly  harder  to  define;  see  C211 

(ii)  Tests.  Conditionals  are  usually  introduced  with  "if-then-else."  However  the  rules  of 
reasoning  (our  axiom  system)  can  be  simplified  by  using  a "smaller"  notion  of  conditional,  the 
test,  which  we  shall  use  in  conjunction  with  the  next  two  constructs  to  synthesize  if-then-else. 
X>0?  is  an  instance  of  a test,  as  is  J=OvPattern(J)=Text(K)?.  In  general  a test  P?  is  constructed 
from  a formula  P of  the  logical  language.  The  idea  of  a test  is  that  a computation  may  proceed 
past  a test  just  when  that  test  evaluates  to  true  in  the  current  environment,  otherwise  the 
computation  must  block  (which  for  our  purposes  is  equivalent  to  going  into  an  infinite  loop). 
Formally,  the  test  P?  is  the  restriction  of  the  identity  binary  relation  on  the  universe  to  those 
states  satisfying  P,  i.e.  {(S,S)I3KP}.  Most  of  what  we  say  holds  even  for  tests  containing 
modalities,  corresponding  to  the  side-effect-free  programming  construct  "if  P would  be  the 
result  of  running  a then»."  However  we  shall  confine  our  examples  to  the  more  familiar 
modality-free  variety. 

(iii)  Alternation.  Execution  of  a|/}  means  the  execution  of  either  one  (but  not  both)  of  a and 
fi,  the  choice  being  made  nondeterministically.  Formally,  the  relation  a\0  is  the  union  of  the 
relations  a and  0. 

(iv)  Sequencing.  Execution  of  a'fi  means  execution  of  first  a then  0.  Formally,  wfi  is  the 
composition  of  oi  and  0. 

Using  tests,  alternation,  and  sequencing,  we  may  express  "if  P then  a else  0”  where  P is  a 
formula  and  a and  0 are  programs,  as  P?;o|-'P?;jJ.  In  effect,  P and  ■'P  act  as  "guards,"  to  use 
Dijicstra's  CS3  terminology.  P?‘,«  can  only  be  executed  when  P holds,  and  conversely  for 
Hence  when  P is  true  P?;«|-'P?;j!  must  be  equivalent  to  a,  and  otherwise  to  0,  which  is  the 
property  "if  P then  « else  0"  should  have. 

(v)  Iteration.  Execution  of  a*  means  executing  a zero  or  more  times,  the  number  of  times 
being  chosen  nendeterministieally.  Formally,  a*  it  the  reflexive  transitive  closure  of  a. 

Using  tests,  sequencing,  and  iteration,  we  may  express  "while  P do  o"  in  much  the  same 
spirit  as  if-then-else,  namely  at  (P;a)*;'>P.  Thit  permitt  a to  be  iterated  for  at  long  at  P 
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remains  true.  Moreover,  the  iteration  may  not  terminate  while  P remains  true,  on  account  of 
the  '•P  guarding  the  exit.  (This  usage  of  a guard  at  the  end  is  not  permitted  in  C51) 

With  these  five  constructs  we  can  express  any  flowchart  program  that  has  decision  boxes 
and  manipulates  arrays.  This  can  be  done  without  introducing  additional  variables.  This 
follows  from  the  fact  that  state  transition  diagrams  can  always  be  translated  into  equivalent 
regular  expressions.  This  is  not  possible  with  assignments,  sequencing,  if-then-else  and  while- 
do  C23,  the  difference  having  to  do  with  the  determinism  of  the  latter. 

Quasi-oroRramming  constructs 

In  addition  to  the  five  constructs  for  our  programming  language,  we  shall  find  two  more 
constructs  of  interest,  not  in  writing  programs  but  in  talking  about  them. 

(vi)  Random  assignment.  X:=?  is  an  instance  of  a random  assignment,  which 
nondeterministically  assigns  an  arbitrary  element  of  the  domain  to  X.  Consider  the  sense  of 
kX:s?3(X<0vX>0).  This  says  that  no  matter  what  element  is  assigned  to  X,  after  the  assignment 
X will  be  either  negative  or  non-negative.  This  captures  what  is  meant  by  VX(X<0vXi0). 
This  demonstrates  that  we  can  introduce  the  ordinary  quantifier  VX  into  dynamic  logic  as  just 
another  modality  CX::?3.  Though  we  shall  adhere  to  the  standard  notations  VX  and  3X  it  should 
be  understood  that  these  stand  respectively  for  CX:=?]  and  <X:=?>. 

(vii)  Converse.  Execution  of  o”  means  the  reverse  execution  of  a.  Formally,  o”  is  the 

converse  of  a,  satisfying  This  permits  us  to  reason  either  forwards  or  backwards 

about  a program's  behavior.  We  mean  this  in  the  sense  that  (i)  [a]P  is  a claim  made  before 
execution  of  a based  on  the  claim  P that  is  supposed  to  hold  after  execution  of  a (backward 
reasoning),  and  (ii)  Ca'DP  is  a claim  made  after  the  execution  of  a based  on  the  claim  P that  is 
supposed  to  hold  before  execution  of  a (forward  reasoning).  We  have  not  capitalired  on 
converse  as  nue«  as  we  would  like  in  our  work  to  date. 

Truth-value  Semantics  of  Dynamic  logic 

Now  that  we  have  settled  on  the  programming  language,  we  can  return  to  the  question  of 
what  ■»CXi«.l]false  means,  or  more  generally  what  any  formula  containing  [a]P  means.  It  is 
important  here  to  realiie  the  distinction  between  truth  and  validity.  What  we  are  about  to 
define  is  the  truth  value  of  a formula  of  dynamic  logic  in  a single  state.  This  is  to  be 
contrasted  with,  say,  Hoare's  notion  of  "P{a}Qr  whose  truth  is  not  defined  on  a state-by-state 
basis  but  rather  is  defined  for  the  whole  universe,  and  so  corresponds  to  the  usual  notion  in 
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logic  of  validity. 

In  state  3,  CalP  is  true  just  when  P is  true  In  every  stale  ^ satisfying  Sa^.  That  Is,  P is 
true  no  matter  which  state  a terminates  in  when  started  in  state  3.  It  follows  that  <o>P  is 
true  just  when  P is  true  in  some  state  3 satisfying  3o3,  that  is,  when  it  is  possible  for  a to 
terminate  and  satisfy  P if  started  in  state  3. 


Expressive  power  of  dynamic  logic 

We  may  now  show  how  dynamic  logic  may  be  used  to  express  a variety  of  concepts. 


P<et>Q  KPaCalQ) 

TerMination  analogue  KP3<a>Q) 

of  P{a>Q 

a»(J  MVX((<a>Y«X)5(<0>Z=X)) 

(This  assumes  that  Y,Z  are  the  respective  output  variables  of  0,0. 

Uhl  la  this  generalizes  to  programs  with  any  finite  set  of  output 
variables,  it  does  not  generalize  to  programs  with  arrays  as  output 
unless  ue  introduce  second  order  quantifiers.) 
a deterministic  hVX(<o>Y-X  o (a)Y=X) 

(As  for  equivalence,  Y is  the  output  variable  of  a.) 
a a I Mays  halts  («<a>true 

a 1-1  »«VX(<o">Y-X  D (a"lY=X) 

o onto  h<of“>truo 


a halts  in  this  state 
ueakest  antecedent 
strongest  consequent 
ueakest  invariant 
strongest  invariant 
convergent 


<a>true 

(olP 

<a“>P 

[a*)P 

<a~*>P 

<a'*'>P 


(see  (9)  for  proof) 

W N N N 

N N N n 


The  reader  wishing  to  pursue  these  concepts  further  is  referred  to  C91  Some  simple 
statements  expressible  in  dynamic  logic  that  do  not  fall  into  any  of  the  above  categories,  and  are 
not  expressible  in  Hoare's  partial  correctness  formalism  or  the  total  correctness  formalism  of 
Manna  and  Waldinger  C17],  are: 


d 


"If  you  sot  Y to  X-fS  and  then 


(Yt-X+StYj-Y+Z*) 
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add  2 to  Y an  indefinite 
number  of  timee  then  it  is 
possible  bu  repeatedly 
emecuting  Y:«Y-1  to  make  Y»X" 

"If  P holds  then  after 
executing  a ue  uill  be  in  a 
state  accessible  via  a from 
some  state  satisfying  P. " 

All  of  the  above  concepts  can  be  stated  in  a second  order  logic  that  permits  explicit 
manipulation  of  states  and/or  programs  as  individuals,  as  in  [33  where  states  can  be  quantified 
over,  or  flOD  where  programs  are  terms.  The  interest  in  dynamic  logic  is  that  it  achieves  its 
expressive  power  using  only  first-order  language.  The  advantage  of  keeping  the  language 
restricted  in  this  way  is  that  it  is  easier  to  completely  axiomatiie  parts  of  the  logic,  though  loops 
present  an  insurmountable  obstacle  to  completeness  as  demonstrated  in  Theorem  16  of  C213. 

i 

1 An  axiom  system  for  dynamic  logic 

» 

r 

I Sefore  axiomatizing  the  programming  language,  let  us  begin  with  a sound  complete  axiom 

system  for  first-order  logic.  A novelty  of  this  system  is  that  it  separates  into  logical  and  non- 
logical  components  what  are  usually  taken  to  be  entirely  logical  rules  and  axioms,  on  the  principle 
that  facts  about  X:s?  are  program-specific  facts.  This  permits  a programmer  to  apply  his 
intuition  about  programs  to  the  problem  of  understanding  the  significance  of  each  axiom. 

Logics  I Axloiwe 

All  tautologies  of  Propositional  Calculus, 
tal  IPoQ)  3 (lalP  3 falQ)  . (Axiom  M) 

Logical  Inference  Rules 

P,  P3Q  H Q . (Modus  Ponsns) 

PH  falP  (Necessi  tation;  subsumes  generalization,  P I-  YxP  ). 

Non- logical  Axioms 

VXP  3 Pj  (any  term  Tj  pj  is  P uith  T for  X) 

P 3 VXP  unless  X occurs  free  in  P 


<Yj -Y-1*>Y=X 


P3  [«]  <a“>P 


Axiom  M can  be  thought  of  as  a claim  about  programs;  it  says  that  for  all  states  9,  if  P 


implies  Q in  every  state  ^ that  can  be  reached  from  S by  executing  a,  and  if  P holds  in  every 
state  ^ similarly  accessible  from  3 via  a,  then  Q holds  in  every  slate  ^ accessible  from  3 via  ot. 


The  second  inference  rule  (the  rule  of  necessitation  of  modal  logic)  can  be  considered  as  an 
upper  bound  on  the  power  of  programs,  which  cannot  falsify  theorems.  If  P is  a theorem  then  P 
is  true  in  every  state,  including  slates  accessible  via  a. 

In  our  system  it  is  straightforward  to  prove  as  theorems  the  axioms  of,  say,  Mendelson's 
system  K CIS]  (p.  57),  and  it  should  be  clear  that  the  second  rule  subsumes  the  rule  of 
generalisation;  in  fact,  if  the  only  modalities  allowed  are  those  with  values  of  the  form  X:=? 
then  the  rule  of  necessitation  |$  the  rule  of  generalisation,  and  the  theorems  of  this  system 
coincide  with  the  theorems  of  K.  It  is  interesting  to  note  that  Mendelson  manages  to  express  as 
one  axiom  what  we  lake  two  to  express,  namely  our  Axiom  M and  the  second  quantification 
axiom.  The  advantage  of  our  decomposition  of  this  axiom  is  that  we  get  two  axioms  about 
quantifiers  that  serve  respectively  as  a lower  and  an  upper  bound  on  what  the  binary  relation 
X:-?  may  be. 

So  far  we  have  only  given  axioms  for  random  assignments.  Now  let  -us  axiomatize  the  four 
loop-free  programming  constructs. 

IP?]Q  ■ PdQ 

CXt«tlP  I Pj^  (see  (211  for  arrag  assignment) 

[a|0]P  a [alP/NiaiP 
(otaiP  m (ai  (0]P 

Interestingly  (but  fairly  obviously,  as  demonstrated  in  C21]),  the  axiom  system  with  these 
four  new  axioms  remains  sound,  complete  and  effective.  (It  is  possible  to  give  further  axioms  to 
handle  the  converse  operation,  still  preserving  soundness,  completeness  and  effectiveness. 
However  we  shall  not  make  use  of  this  in  the  following.) 

A derived  rule 

We  could  at  this  point  proceed  with  the  discussion  of  our  ultimate  objective,  the 
construction  of  a proof-checking  program  that  would  check  proofs  expressed  in  the  above  axiom 
tyatem.  Unfortunately  the  above  system  is  too  weak  to  permit  reasonably  succinct  proofs;  for 
example,  it  appears  that  6 lines  are  needed  to  prove  <X:=1>X=1  from  the  assumption  1^1  using  the 
above  system.  In  this  section  we  explore  a derived  rule  with  an  eye  on  strengthening  the  axioms 
and  rules.  In  this  respect  we  are  emulating  J.A.  Robinson  C22],  who  prescribed  a new  rule  to 
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facilitate  the  construction  of  automatic  theorem-provers.  The  constraints  on  a proof-checker 
are  somewhat  different  from  those  of  a theorem-prover,  and  the  arguments  for  Robinson's 
resolution  rule  are  not  sufficiently  compelling  for  us.  In  particular,  the  convenience  of  having  a 
clause  as  the  unit  of  information,  which  helps  an  automatic  theorem  prover  organize  the  proof, 
may  be  more  hindrance  than  help  in  a proof-checker  because  the  user  may  not  have  conceived  his 
proof  in  terms  of  clauses  that  are  disjunctions  of  literals.  This  is  not  to  say  that  we  shall  not 
make  use  of  unification;  indeed,  unification  is  a most  valuable  tool  in  automated  logic. 

We  now  give  the  details  of  the  rule,  which  we  call  the  Show  Rule  for  lack  of  a more 
descriptive  term.  A proof  step  using  it  looks  like 

Show  S <p9>  using  TO  <p0>,  T1  <pl>,  T2  <p2>,  ... 

For  the  moment  ignore  the  items  inside  braces  { }.  Ideally,  we  would  like  this  rule  to  apply 
whenever  the  formulae  TO,  Tl,  T2,  ~ logically  entail  the  formula  S,  a semantic  characterization 
of  the  rule.  Unfortunately  that  would  lead  to  a non-effective  proof-checker,  since  logical 
entailment  is  not  even  partially  decidable  for  our  language  C9].  Instead  we  resort  to  an  effective 
syntactic  characterization.  This  is  where  the  items  in  braces  enter  the  picture.  The  braces 
enclose  "templates”  which  contain  the  propositional  content  of  the  proof  step,  in  the  sense  that 
each  template  is  a propositional  "approximation"  to  the  formula  it  follows.  For  example,  we  might 
say 

Show  [Xt  =1  |X: s2]X>0  <p/\q>  using  1>0  {p>,  2>0  <q>. 

The  template  pAq  refers  to  the  result  of  expanding  CX:  = 1|X:=2]X>0  first  to 
CX:=1]X>0aCX:=2]X>0  and  then  to  1>0a2>0.  It  should  be  clear  that  the  two  uses  of  p in  the 
templates  refer  to  the  same  formula,  1>0,  and  similarly  for  the  two  uses  of  q.  More  generally,  we 
shall  require  only  that  multiple  occurrences  of  the  same  letter  refer  to  unifiable  formulae. 

We  check  this  proof  step  in  two  phases,  which  can  be  done  independently  and  in  either  order 
(or  in  parallel  by  two  processors).  One  phase,  called  IDENTIFY,  is  to  check  that  repetitions  of 
the  same  letter  can  be  justified.  We  do  this  by  attempting  to  unify  corresponding  formulae.  The 
other  phase,  called  VERIFY,  is  to  see  whether  the  templates  alone  constitute  a sound  argument  in 
modal  propositional  logic.  In  this  example  all  modalities  were  eliminated  so  that  we  were  left 
with  the  argument 


Show  PAq  using  p,  q 
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which  is  in  fact  a sound  argument  of  non-modal  propositional  logic.  A situation  where  modal 
logic  would  help  i$: 

Show  tU|V]Y>0  <(a]  [(J]p> 

using  (UlX-1  <(a]q>,  X.l3(V]Y>0  <qD[a]p>. 

Hors  ws  are  dealing  with  "uninterpreted"  programs  U and  V,  a situation  that  arises  when  we  are 
given  a program  about  which  we  have  previously  proved  some  useful  properties  and  whose  code 
we  no  longer  wish  to  be  bothered  with.  (This  situation  arises  frequently  in  the  extended 
example  of  the  next  section  but  one.)  In  this  case,  knowing  nothing  about  the  programs  U and  V 
beyond  the  facts  given,  we  could  not  expand  them  in  the  way  we  did  with  CX:=1],  so  they  carry 
over  to  the  templates.  Here  the  argument  of  modal  logic  is: 

Shou  [q]  [0]p  using  (olq,  qp[|3]p. 

This  argument  can  readily  be  seen  to  follow  if  we  apply  Necessitation  to  q:3[/9]p  to  get 
Ca](q3C/9]p)  and  hence  Ca]q3[ei]CU]p,  The  rest  is  propositional  reasoning. 

The  IDENTIFY  phase  begins  by  determining  what  subformula  each  occurrence  of  a template 
letter  refers  to.  This  is  done  by  systematically  expanding  the  formula  associated  with  the 
template  containing  the  given  letter  until  the  formula  can  be  matched  to  the  template.  Thus 
CU;V3CWDX=0  will  match  Ca3C/9]p  directly  with  a matched  to  U;V,  b to  W and  p to  X=0.  However 
CU;V]X?0  will  not  match  [a]C/5]p  directly  but  must  first  be  expanded  as  [U]CV]X=0.  [V|WDX=0 
will  not  match  pAq  directly  but  must  first  be  expanded  as  [V]X=0a[W]X=O.  Once  the  formula 
matches  the  template,  the  subformula  corresponding  to  each  letter  can  immediately  be 
determined.  Then  all  the  subformulae  corresponding  to  occurrences  of  the  same  letter  are 
checked  for  whether  they  can  be  unified.  This  may  require  further  expansion;  for  example, 
attempting  to  unify  CX:sl]X>0  and  W>0  involves  eliminating  the  assignment  modality  to  give  1>0, 
and  instantiating  W as  1,  this  latter  step  being  performed  by  a unification  algorithm.  All 
instantiations  necessary  must  be  compatible  with  each  other. 

Any  formulae  that  fail  to  unify  are  put  to  one  side  while  the  remainder  of  the  proof  step  is 
checked.  When  that  is  done,  then  the  failed  pairs  are  expressed  as  an  equivalence  and  tested  by 
a routine  that  checks  for  validity  of  quantifier-free  Presburger  arithmetic,  in  the  hope  that  the 
formulae  turn  out  to  be  equivalent  on  arithmetic  grounds.  (This  together  with  the  Rule  of 
Convergence  described  in  the  next  section  is  the  only  concession  to  domain-dependencies  in  the 
system.) 
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The  VERIFY  phase  is  a satisfiability  tester  for  modal  propositional  logic.  It  begins  by 
determining  what  applications  of  the  Rule  of  Necessitation  are  sufficient  to  make  the  proof  go 
through.  Boxes  are  then  eliminated  from  the  formula  by  the  appropriate  generalization  of  the 
transformation  <o>P/\C«]Q  ->  <a>(PAQ),  which  preserves  satisfiability  for  the  intuitively 
obvious  reason  that  CalQ  acts  only  as  a constraint  on  those  worlds  one  might  construct  (in 
attempting  to  satisfy  <a>P)  that  are  accessible  via  a and  satisfy  P,  namely  that  in  any  such  world 
Q must  be  true.  In  our  present  implementation,  we  first  eliminate  all  top-level  propositional 
letters  by  expressing  the  formula  in  conjunctive  normal  form  and  applying  the  Davis-Putnam 
algorithm  for  each  of  those  letters.  Then  we  convert  the  resulting  formula  involving  only 
modalities  to  disjunctive  normal  form  and  apply  the  above  transformation.  Then  the  process  is 
repeated  on  the  arguments  of  the  top-level  diamond  modalities.  Though  this  approach  can  be 
ioeffic’ent,  in  practice  on  the  kinds  of  formulae  we  encounter  it  is  the  most  efficient  of  the 
methods  we  have  tried.  With  all  boxes  eliminated,  the  satisfiability  of  the  result  no  longer 
depends  on  the  names  of  the  diamonds;  that  is,  <a>Pv</9>Q  and  <a>Pv<a>Q  are  equally 
s:^tisfi^ble.  Indeed,  satisfiability  of  the  whole  is  preserved  if  <a>P  is  replaced  by  true  when  P is 
satisfiable  and  false  when  not.  Thus  we  can  proceed  recursively,  working  up  from  the  lowest 
diamonds  to  determine  satisfiability  of  progessively  larger  portions  of  the  formulae. 

Axioms  for  programs  with  loops 

For  programs  with  loops  we  have  the  following  axioms  and  rules. 

<a'^>P  3 <a*>P  AKiome  of  Intent  (one  for  each  n) . 

PafalP  H P3[a’'']P  Rule  of  Invariance. 

n>z  A P A Q(n)  D <a>3u(z^u<n  a Q(u)) 

H n2z  A Q(n)  a <0*>(-«PA3H(zSwSnAQ(n))  v Q(z)) 

Rule  of  Convergence 

These  axioms  and  rules  are  explained  and  justified  in  more  detail  in  121].  The  first  says  that 
if  a can  halt  in  some  number  of  steps  then  a*  can  halt.  The  second  says  that  if  a leaves  P 
unchanged,  then  so  does  a^.  (Observe  how  convenient  it  is  to  reason  about  iteration  expressed 
in  this  form.)  The  third  says  that  if  a "drives"  towards  z without  passing  it,  provided  P remains 
true,  then  eventually  a*  will  either  make  P false  somewhere  on  the  way  to  z,  or  it  will  reach  z. 
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Example  proof 

The  following  program  was  devised  by  Manna  and  Pnueli  [161  to  illustrate  the  efficacy  of 
their  method  of  proving  termination. 

V t.  0} 

uh i I e X 4 0 do 

(Mhile  X d 0 do  (X  i.  X-1;  Y i«  Y^l); 

Y I.  Y-l» 

while  Y d 0 do  (Y  Y-1;  X :*  X+IH 

This  program  represents  an  obscure  way  of  setting  both  X and  Y to  0,  namely  by  first 
setting  Y to  0,  then  copying  X into  Y by  repeatedly  decrementing  X and  incrementing  Y,  then 
decrementing  Y once,  then  copying  Y back  into  X by  repeatedly  decrementing  Y and  incrementing 
X.  This  process  is  repeated  until  X becomes  0.  The  point  of  this  example  was  that  it  was 
supposed  to  be  difficult  to  prove  termination  of  this  program  by  Floyd's  method  but  easy  by  the 
method  described  by  Manna  and  Pnueli.  Our  own  interest  in  this  program  besides  the  question  of 
ease  of  proving  termination  (not  a problem  in  dynamic  logic)  is  that  it  is  just  the  right  site  to 
illustrate  the  proof  techniques  appropriate  to  dynamic  logic. 

We  may  write  this  program  in  the  programming  language  dynamic  logic  caters  for  thus. 

Pit  X>0?j  Xi-X-lj  Yi-Y+1. 

P2t  Y>0?»  Yt.Y-lj  X»-X+l. 

P3i  X>0?j  Pl*i  X-0?|  Yi-Y-l;  P2*i  Y-0?. 

P4i  Yi-Oi  P3*»  X-0?. 

PI  represents  one  step  of  "copying"  a number  from  X to  Y,  while  P2  represents  one  step  of 
copying  from  Y to  X.  P1*;X=0?  and  P2*;Y=0?  each  represent  the  entire  copying  process,  from  X 
to  Y and  back  again.  P3  amounts  to  a program  that,  provided  Y is  initially  0,  decrements  X.  P4  is 

then  the  whole  program  for  setting  X and  Y to  0.  The  statement  we  want  to  prove  is,  <P4>t  (t 

denotes  true),  which  asserts  that  it  is  possible  for  P4  to  halt.  The  following  is  the  proof,  which 
uses  7 hypotheses  from  arithmetic  and  13  theorems.  This  proof  is  machine-readable. 

X The  nanna-Prvuel  I program  X 
Pit  X>0?|  Xi-X-li  Yi-Y+1. 

P2i  Y>0?|  Yi-Y-li  Xt.X+1. 

P3i  X>07|  Pl*t  X-0?t  Yi-Y-1»  P2*i  Y.0?. 
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P4i  Yi.Oi  P3*j  X-0?. 

X Formulae  occurring  common  I g in  the  proof  X 
AK(n)i  XanAYaO.  BK(m,n):  XanAX+Ysm. 

Ag(n)i  YanAXaQ,  Bg(m,n)t  YanAX'fYam. 

X Aeeumptions  from  arithmetic  - not  proved  here  X 
Hit  Zan^l  ■ Z-lan.  H2t  U-n^l  s U>0. 

H3t  Ax(n)  a B><(n,n).  H4t  Agin)  ■ Bg(n,n). 

HSt  Anin)  ■ Bg(n,0).  HBt  Agin)  i B>cin,0). 

H7i  UaU. 

Thmlt  Bxim,n-fl)  o <Pl>BK{m,n). 

Shou  Thml  <pAr  o <a7>ipAr)>  using  H2  <po8>. 

ThmZi  Bgim,n+1)  d <P2>Bgim»n). 

Shou  Thm2  <pAr  d <8?>ipAr)>  using  H2  tp38>. 

Thm3i  BKim,n)  3 <Pl*>Bxim,0) . 

Use  Convergence  in)  Thm3  from  Thml. 

Thm4:  Byim^n)  3 <P2*>Byim,0) . 

Use  Convergence  in)  Thm4  from  Thm2. 

ThmSt  Ax  in)  3 <Pl*>Ayin), 

Shou  ThmS  <p3<a>q> 

using  Thm3  {p3<a>q>. 

ThmSt  Axin+1)  3 <Pl*>Ayin+l) . 

Shou  ThmS  <p>  using  Thm3  <p>. 

Thm7t  Agin)  3 <P2*>Axin). 

Shou  Thm7  <r3<a>s> 

using  Thm4  <p3<a>q>,  H4  <rsp>,  H5  <siq>. 

ThmSt  Agin+l)  3 <Yi  aY-l>Agin) . 

Shou  ThmS  <pAr  3 qAr>  using  HI  <piq>. 
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ThM9i  AK(n-«-l)  3 <P3>Ax(n). 

Shou  Thiii9  <xnl/\yO  3 <xp?ia{xO?jdy;b;yO?>{xnAyOI> 
using  H2  <xnl3xp>, 

ThhiB  <xnlAyO  3 <a>  (ynlAxO)>, 

Th»7  CynAxO  3 <b>(xnAyO)>, 

ThinS  <ynlAxO  3 <dy>(ynAxO)>. 

ThnlOt  Ax(n)  3 <P3*>Ax(0). 

Use  Perfornance(n)  ThelO  fron  TheS. 

Thellt  X-n3<Yt-0>(K.nAY.0). 

ShoH  Thell  <p3pAq>  using  H7  <q>. 

Thnl2i  X«n3<P4>t. 

Shou  Thml2  <p3<a;c»r?>t> 

using  ThelO  <pAq3<c>(rAq)>,  Thell  {p3<a>(pAq)>. 

Thel3t  <P4>t. 

Shou  Thel3  <p>  using  Thel2  <q3p>«  H7  {q}. 

To  avoid  being  distracted  by  extraneous  issues  such  as  arithmetic  truth  we  have  introduced 
all  arithmetic  facts  in  this  proof  as  assumptions.  (In  fact,  in  the  implemented  system  we  have  a 
very  fast  proof-checker  for  quantifier-free  Presburger  arithmetic,  using  quasi-Caussian 
elimination.) 

The  above  proof  is  not  the  largest  proof  we  have  successfully  checked  with  our  system.  A 
substantial  part  of  a total  correctness  proof  of  the  Knuth-Morris-Pratt  pattern-matching 
algorithm  has  been  machine-checked,  and  we  are  in  the  process  of  completing  this  proof.  This  | 

extends  work  on  the  partial  correctness  of  this  algorithm  by  Wegbreit  C24]. 

Discussion  of  the  proof-checker 

We  have  constructed  a system  for  checking  proofs  of  the  kind  exemplified  above.  In  this  we 
are  following  in  the  footsteps  of  Milner  120,21,26],  who  is  doing  for  Scott's  Logic  of  Computable 
Functions  what  we  are  doing  for  the  above  modal  extension  to  first-order  logic.  Inasmuch  as  we 
are  treating  programs  that  manipulate  their  environments,  we  are  also  continuing  a tradition  of  ; 

several  years  of  implementing  systems  for  proving  and  checking  proofs  of  properties  of  programs  j 

14,84344,23,241  However  the  greater  expressive  power  of  dynamic  logic  compared  to  that  of  j 
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partial  correctness  assertions  (the  language  used  in  almost  all  such  systems)  adds  considerably  to 
the  interest  of  our  system.  This  consideration  actually  makes  Milner's  system  a closer  relative 
of  ours  than  the  partial  correctness  systems,  due  to  the  greater  emphasis  on  "expressions  as 
first  class  citiiens"  in  Milner's  system  and  ours,  resulting  in  a logic  where  programs  and  facts 
mingle  more  freely  than  say  with  Hoare's  notation.  The  major  difference  between  Milner's 
system  and  ours  is  the  LCF  treatment  of  programs  (computable  functions)  as  individuals  in  the 
underlying  domain  versus  our  treatment  of  programs  as  "adverbs,"  analogously  to  quantifiers. 

Another  system  related  to  ours  is  Richard  Weyhrauch's  [1,2$]  FOL  (First-Order  Logic)  proof- 
checker.  A detail  in  which  our  program  differs  from  Milner's  and  Weyhrauch's  (apart  from  the 
obvious  one  of  choice  of  logical  language)  is  that  our  program  makes  less  of  an  effort  to  help  the 
'jser  interactively  than  is  done  by  either  LCF  or  FOL,  but  rather  is,  at  least  thus  far,  a system  in 
which  the  user  prepares  his  proof  exactly  as  though  he  were  writing  a program.  This  means  that 
his  prook*  exists  on  a file  and  is  read  by  the  proof-checker  just  as  an  interpreter  reads  a program 
from  a File.  This  has  permitted  us  to  focus  all  of  our  effort  on  the  proof-checker  proper. 

The  proof-checker  is  implemented  on  the  PDP-10  computer  at  M.I.T.'s  Artificial  intelligence 
Laboratory.  The  program  written  to  date  has  aproximately  100  LISP  functions  comprising  a total 
of  180C  lines  of  code  averaging  ♦ LISP  atoms  per  line.  The  bulk  of  this  code  is  for  formula 
manipulation.  However,  a small  amount  of  it  is  for  book-keeping  tasks  of  a relatively  minor 
iMture  associated  with  keeping  track  of  the  structure  of  a proof. 

Directions  for  further  research 

Although  our  immediate  goals  may  net  appear  to  be  particularly  ambitious  or  difficult  to 
achieve,  as  well  as  not  being  obviously  "Artificial  Intelligence”  research,  we  admit  to  far  more 
ambitious  and  less  plausible  objectives  on  a larger  lime  scale.  Ultimately  we  see  the  proof- 
checker  itself  becoming  a component  of  a variety  of  very  intelligent  program-manipulating 
progran.s.  This  depends  on  our  belief  that  the  ability  to  check  proofs  is  a vital  part  of  any  i 

program  that  pretends  to  "understand"  some  domain  of  discourse  where  the  discussion  is  at  all 
involved.  Two  applications  that  we  would  like  to  explore  when  the  proof-checker  has  reached  a 
satisfactory  I'ivel  of  performance  are  (i)  the  automatic  production  of  reliable  software  and  (ii) 
machine-mediated  reasoning  about  programs.  Our  plan  of  attack  for  each  of  these  areas  is  not 
presently  so  crisp  that  we  would  feel  confident  embarking  on  either  area  forthwith,  particularly 
the  second,  but  we  can  nevertheless  at  this  early  stage  present  thoughts  on  these  subjects. 

The  notion  of  program  reliability  through  correctness  proofs  has  gained  momentum  in  the 
past  few  years,  spurred  on  most  notably  by  the  axiomatic  methods  of  Floyd  C7]  and  Hoare  [11]. 

As  yet  there  is  not  a shred  of  hard  evidence  to  suggest  that  this  approach  supplies  the  most 
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•conomiol  approach  to  reliability  (where  the  economics  lakes  into  account  both  the  cost  of 
having  unreliable  software  and  the  total  programming  and  maintenance  cost),  indeed,  it  may  well 
turn  out  that  the  bulk  of  the  problems  encountered  today  with  unreliable  software  may  be 
disposed  of  by  a happy  combiitation  of  a good  programming  language  and  a clean  programming 
style.  Nevertheless,  if  the  proof-oriented  approach  can  be  made  to  work  and  does  not  put  too 
great  a burden  on  the  programmer  and/or  the  computer,  it  may  provide  reliable  software  at  low 
cost.  We  feel  it  is  well  worth  continuing  the  experiments  that  have  been  going  on  in  this  area  in 
the  past  few  years.  Although  these  experiments  have  not  thus  far  demonstrated  the  value  of 
correctness  proofs,  it  is  still  too  early  to  draw  any  negative  conclusions  about  the  method  in 
general. 

From  a longer -range  viewpoint,  the  burden  of  programming  should  become  progressively 
more  the  computer's  responsibility,  requiring  the  computer  to  "understand"  better  the  programs 
it  executes.  This  has  been  the  trend  since  the  first  assembler  was  used,  and  though  the  trend  is 
perhaps  not  as  pronounced  as  some  have  hoped,  there  is  no  doubt  that  the  trend  continues.  As  it 
does,  methods  of  reasoning  about  programs  will  concomitantly  become  a more  essential  part  of 
the  computer's  repertoire.  This  raises  the  question  of  the  choice  of  language  most  appropriate  to 
such  reasoning.  In  view  of  the  expressive  power  of  dynamic  logic  we  feel  that  it  is  worth 
developing  the  methodology  of  reasoning  in  this  language  with  an  eye  to  automating  the  reasoning 
as  far  as  possible.  A program  like  our  proof-checker  is  precisely  what  is  needed  in  the  way  of  a 
"black  box"  that  "accepts"  a reasonably  sized  step  in  a discussion  about  a program.  The  sort  of 
machine-mediated  discussions  we  envisage  could  quite  well  be  cast  as  proofs,  albeit  in  the  form 
of  a dialogue.  If  the  notion  of  a dialogue  as  a proof  seems  strange,  visualize  a conversation  - 
about  a program  - punctuated  with  "I  don't  see  why  you  need  that  test  there"  and  "How  do  you 
guarantee  that  X will  never  become  negative?"  Such  conversations  about  programs  arise  all  the 
time,  and  it  is  clear  that  the  questions  are  referring  to  proofs,  probably  expressed  informally  but 
proofs  nonetheless.  One  might  argue  that  proof-checking  is  not  understanding,  but  we  would 
insist  that  it  is  at  least  a component  of  understanding. 

As  humans  are  taken  progressively  further  out  of  the  loop  (admittedly  a very  long-range 
view)  the  dialogue  will  become  more  of  a monologue.  However  it  may  still  be  appropriate  for  the 
computer  to  reason  about  the  programs  it  is  contemplating  using  a language  like  dynamic  logic. 
Thus  even  in  this  scenario  the  basic  proof-checking  methodology  may  continue  to  be  used.  We 
should  add  that  we  see  nothing  strange  in  the  idea  of  a computer  checking  proofs  that  it 
fenerated  itself;  the  best  way  to  generate  proofs  may  be  to  propose  possibly  faulty  proofs  and 
subject  them  to  detailed  criticism.  This  would  require  not  only  the  error-detecting  capability  of 
our  proposed  proof -checker  but  error-correcting  capabilities  as  well. 
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